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Abstract — Software defined networking is being introduced to 
many networks. The most widely adopted open source software 
switch with software defined networking support is the Open 
vSwitch. The Open vSwitch, just as current hardware network 
devices, provides support for network monitoring, which is an 
integral part of a network management process. For this reason, 
this paper focuses on analysing the quality of flow monitoring 
features of the Open vSwitch. We propose and perform several 
tests of the essential flow monitoring capabilities and show 
that the current flow measurement process has several crucial 
deficiencies. 


I. Introduction 

Software defined networking (SDN) [1] is an emerging way 
of managing networks. It decouples the network control and 
forwarding functions, which enables administrators to directly 
program the network behaviour and flexibly change it accord- 
ing to their needs. The leading open source implementation 
of SDN software switch is the Open vSwitch (OVS) [2], It 
supports many virtual platforms, network and management 
protocols. We believe that SDN could increase the potential 
for detection and mitigation of network attacks, as described 
in [3], that are handled in a standard network only with 
difficulty. 

An integral part of network management, as well as detec- 
tion and mitigation of network attacks, is network monitoring. 
Administrators must be aware of link utilization and perfor- 
mance bottlenecks, as well as security issues. One of the most 
widely adopted solutions for network monitoring is flow moni- 
toring [4]. There are several protocols used in flow monitoring; 
sFlow [5], NetFlow [6] and IPFIX [7]. The Open vSwitch 
supports all of these protocols, according to its documentation. 
However, to be able to utilize the collected flow data for 
security monitoring, high level of measurement precision must 
be assured. Many anomalies and attack detection methods 
depend on a correct data and may yield false positives when 
supplied with incomplete or erroneous data [8]. However, 
different implementations of flow monitoring protocols are 
known to have measurement artifacts, as described in the 
works of Cunha et al. [9] and Hofstede et al. [10]. To deploy 
network attack detection and mitigation solutions in SDN 
networks using Open vSwitch, the correctness of the generated 
flow data needs to be ensured. 

The goal of this work is to evaluate the Open vSwitch’s 
implementation of flow measurement and export using Net- 
Flow v5 and IPFIX protocols. We propose and perform tests 
that cover the most important features of the flow monitoring 
process. We verify flow expiration timeouts, the correctness 


of exported values, support for network protocols and packet 
fragmentation. The results show that the data exported by IP- 
FIX and NetFlow v5 differ significantly, even when exporting 
the data using both protocols at the same time. We describe 
the observed measurement artifacts in detail. Moreover, the 
source code for generating the test traffic and captured packet 
samples are made available as a part of our contribution. This 
is the first work to evaluate Open vSwitch implementation of 
flow export to the best of our knowledge. The reader of this 
paper should be well familiar with flow measurement at least 
in the scope of [4], 

This paper is divided into four sections. The Section II de- 
scribes measurement setup. The Section III presents measured 
artifacts and results of the flow monitoring evaluation. The 
Section IV concludes the paper and recommends improve- 
ments to the measurement process of the Open vSwitch. 

II. Measurement Setup 

The measurement is performed using KYPO Cyber Exercise 
& Research Platform [11], which enables us to easily build 
required network topology. We generate test traffic, send 
it through the Open vSwitch and capture exported IPFIX 
and NetFlow v5 data. The rest of this section describes the 
topology, traffic generation, Open vSwitch configuration, and 
measurement verification in detail. 

A. Network Topology 

We deploy a simple network depicted in the Figure 1. The 
testbed has one switch with two hosts. The traffic generator 
is deployed on the Hostl. It generates well-defined traffic 
directed towards the Host2. Since exported flow records are 
unidirectional, the Host2 could drop all incoming traffic with 
no impact on exported flow records. Moreover, it keeps back- 
ground traffic exported in flow records on minimum. Export 
of network flows is configured on the switch node OVS and it 
monitors all traffic forwarded through the switch. 



Fig. 1. The network topology of the testing sandbox in KYPO. The export 
of network flow data is set on node OVS. The traffic is generated from Hostl 
towards Host2. 




B. Traffic Generation 

To test the implementation of the flow export we generate 
standard TCP, UPD and ICMP packets with and without 
payload. This allows us to assess the results exported by 
the switch. The generated traffic is used to evaluate flow 
expiration, export of TCP flags, byte and packet counters, and 
other values. 

Monitored traffic is generated using Scapy [12], standard 
ping and ping6 tools. Scapy is a packet manipulation program 
that enables users to easily forge network packets. Scapy is 
used to generate traffic for all tests described in the Section III 
except for the packet fragmentation test. The ping tool is used 
to perform the packet fragmentation test. Detailed description 
of the generated traffic is provided together with the results in 
the Section III. 

Since there is no background traffic, we are easily able 
to confirm or disprove correctness of exported flow records 
according to generated traffic. Moreover, we compare received 
traffic using packet capture on Host2 to see whether it meets 
expectations. The functions and scripts used for traffic gener- 
ation with packet capture files of exported flows are publicly 
available [13], 

C. Open vSwitch Configuration 

We use Open vSwitch version 2.4 [14] released in August 
2015 for the testing. However, the most recent changes in 
NetFlow or IPFIX export were committed in version 0.9.70 
and 2.2, respectively [15]. The Open vSwitch is installed on 
Debian 7.0 system with kernel 3.19 which includes the OVS 
kernel package. 

The Open vSwitch can export network flow data in three 
different formats - NetFlow, sFlow, and IPFIX. We test 
NetFlow and IPFIX as most commonly used network flow 
formats. Both flow formats have their own configuration table 
and are able to run simultaneously. The switch is configured 
using following commands: 

NetFlow v5 configuration: 

$ ovs-vsctl set Bridge brO netflow=0nfO — \ 

— id=@nf0 create NetFlow \ 
targets=\" 172. 16. 1.1: 4006V 
active-timeout =3 00 

IPFIX configuration: 

$ ovs-vsctl set Bridge brO ipfix=0ipO — \ 

— id=0ipO create IPFIX \ 
targets=\" 172 .16.1.1:4005\" \ 
obs_domain_id=l \ 
obs_point_id=l \ 
cache_active_timeout=300 \ 
cache_max_f lows=10 

D. Measurement Verification 

Flow records exported in both NetFlow v5 and IPFIX 
formats are captured by tcpdump [16] in a format of packet 
capture files. The tcpdump is run on the OVS node. We use 
Wireshark [17] network protocol analyser to process acquired 
data. The reason for not using any existing flow collector for 
data analysis is that the data might be misinterpreted during 
the storage or analysis itself. We compare the values reported 


by Wireshark with the raw data stored in the captured packets 
to eliminate a possibility of data misinterpretation. 

We focus on the validation of several common artifacts 
found in the flow measurement process; the flow record expira- 
tion, the correctness of exported values, supported protocols, 
and handling of fragmented packets. Each of these aspects 
can significantly impact the output of flow based anomaly 
and attack detections. When flow records are not expired 
consistently, methods relying on a number of packets in a 
single flow might fail. Exporting incorrect data might also 
easily confuse detection methods. It was shown by [18] that 
flow sampling might negatively impact detection methods. 
Therefore, when incomplete data are exported, it impacts the 
detection rate as the data loss can be seen as uncontrolled flow 
sampling. However, we did not perform stress testing of the 
Open vSwitch under heavy traffic since we were limited by 
the virtual environment in the amount of traffic that we were 
able to generate. Packet fragmentation is often a problem for 
flow monitoring systems since first packet fragments usually 
create one flow record with Layer 4 information and following 
fragments create another flow record without Layer 4. An 
attacker can try to avoid threshold based detection methods by 
sending fragmented packets that will cause his communication 
to be recorded in a larger number of flow records that cannot 
be aggregated. Measurement of each artifact of the flow 
measurement is described in Section III together with acquired 
results. 

III. Artifact Measurement and Results 

We devised a series of measurements to verify most com- 
mon artifacts found in the flow measurement process. De- 
scription of each measurement together with evaluation and 
discussion of the results is provided in the rest of this section. 

A. Flow Expiration 

The requirements for flow expiration are not strict. The 
RFC 5470 [19] specifies only that flow is considered to be 
expired when no packets belonging to this flow have been 
observed for a period of time. It recommends that the time 
period should be configurable. This period is usually called the 
inactive timeout. Other possible conditions are mentioned as 
well; lack of resources and regular expiration of long-running 
flows. The interval after which long-running flow should be 
expired is called active timeout. Some devices are also known 
to implement flow expiration of TCP flows after encountering 
a RST or FIN TCP flag. The RFC 5470 covers only IPFIX 
protocol, however, NetFlow v5 uses the same concept of flow 
expiration. 

Inactive timeout is not configurable in Open vSwitch. It is 
connected to expiration of records from a routing cache of the 
switch, according to information provided by its developers. 
Therefore, the inactive timeout depends upon link utilization 
and saturation of the routing cache. To be sure that a flows do 
not expire due to inactivity, we need to send a packet at least 
each second to keep the flow active. 



Active timeout can be configured both for NetFlow v5 
and IPFIX protocols. We designed following test to verify 
whether the active timeout is honored in flow expiration. A 
traffic containing 2150 packets sent in 0.7 second intervals 
is generated and sent through the Open vSwitch. We test two 
values of the active timeout: 10 seconds and 300 seconds. The 
first value is impractical in large networks, but may be used 
to perform near real-time monitoring in small environments. 
The second value is used as a default for flow measurement 
in large networks. The interval between packets was chosen 
to minimise sending the packets exactly at the end of active 
timeout interval. The measurements were performed for UDP 
and TCP protocol. 

Since the gap between generated packets is not exactly 
0.7 seconds, we measured the intervals by monitoring the 
incoming packets and noting their arrival timestamps. The av- 
erage inter-arrival time of the packets is 0.703 s with standard 
deviation of 6, 43 • 10 -4 s, which was computed from 1000 
observed packets. Due to the average interval between packets, 
we expect each flow that reaches the active timeout to have 
14 to 15 packets for the 10 s timeout and 426 to 428 packets 
for the 300 s timeout. The Figure 2 shows both possible cases 
where a flow contains N — 1 or N packets. It is possible to 
have even TV — 2 in case of the 300 s active timeout due to the 
deviation of inter-arrival times. 
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Fig. 2. N or N — 1 packets captured in a flow. 

The flow records reported using IPFIX protocol were incon- 
sistent and wrong. Number of packets reported for each flow 
was a multiple of 400, even when only 14 to 15 packets were 
expected. Moreover, the duration of the flows did not match 
either. Some flows had reported duration of zero seconds, 
some even negative. Therefore, further evaluation of IPFIX 
flow export of the Open vSwitch was not possible. Due to 
the reported issues, the IPFIX flow export cannot be used for 
network monitoring purposes and will not be further evaluated 
in the rest of this work. 

The NetFlow v5 flow export results are usable, however, 
there are a few irregularities in the usage of the active timeout. 
When a flow record expires due to the active timeout, it is 
exported, but a flow duration is not reset. As a result, each 
subsequent flow record exported due to the active timeout has 
a duration of approximately multiple of the active timeout (the 
duration of N th flow is TV • timeout ± e). Therefore, we need 
to compute an absolute length of each flow record to get a 
useful value. Table III-A shows average absolute values of the 


TABLE I 

Flow duration for 300 s active timeout 



UDP 

TCP 

Packets 

Duration 

Packets 

Duration 

Flow 1 

427 

299.321 s 

428 

300.086 s 

Flow 2 

428 

300.738 s 

426 

299.398 s 

Flow 3 

427 

300.025 s 

428 

300.788 s 

Flow 4 

427 

300.028 s 

427 

300.092 s 

Flow 5 

427 

300.047 s 

427 

300.101s 

Flow 6 

14 

9.835 s 

14 

9.838 s 


flow duration for the 300 s active timeout. The duration of the 
first flow is correctly calculated as ( packets — 1) • gap_length 
(e.g.: two packet flow should have exactly duration of the inter- 
arrival time). The duration of subsequent flows is calculated 
starting from the last packet of the previous flow, which is a 
result of not zeroing the start of the flow counter. However, 
the duration reported by last the flow record is correct. The 
values for the 10 s active timeout are not presented here, but 
the measurement confirmed that the flow duration and packet 
counts are correct. 

The active timeout is correctly applied using the NetFlow v5 
flow export. We observed no difference while testing using 
TCP and UDP protocol. Our measurements indicate that when 
new packet is encountered and the duration of the flow exceeds 
multiple of active timeout length, the packet is included in the 
flow record and the flow is exported. This implementation is 
correct, however, other implementations might export the flow 
before including the new packet and use the new packet to start 
new flow record. Start of the flow record should be computed 
as an arrival time of the first packet of the flow record. 

FIN/RST TCP flags are used by some vendors, such as 
Cisco [20], to expire a flow record when encountering a packet 
with FIN or RST TCP flag set. We sent 20 packets in a single 
flow record and set TCP flags of the 10 th and 20 th to RST, FIN 
and their combination in three subsequent tests. Since the flow 
record was not expired upon encountering a packet with TCP 
flags set, we conclude that TCP flags are not used for flow 
expiration by NetFlow v5 flow export. The fact that the Open 
vSwitch does not implement this behaviour should be taken 
into consideration when configuring attack detection methods. 

B. Value Validation 

Correctness of values in flow records is essential for the 
usability of any flow based monitoring system. Packet and byte 
counters are depended upon by almost every threshold based 
detection method. TCP flags are often used to detect flood, 
DoS and DDoS attacks. We have already verified that flow 
start and flow end timestamps are correctly exported, although 
the flow start value is not zeroed when flow expired due to 
active timeout. We have also checked all other values stored 
in a flow record during the validation as described further in 
this section. 

TCP flags are exported for TCP flows. We have verified 
that the export if the flags by sending two packets, one with 


none of the flags set and the other with all of the flags set. 
The values were reported correctly. We have also verified that 
sending eight packets each with different TCP flag set results 
in a flow with all TCP flags set and that each flag is exported 
correctly. We conclude that TCP flags are correctly exported 
using the NetFlow v5 protocol. 

Byte count is expected to report a total number of Layer 3 
bytes in the packets. It was tested simply by sending a single 
packet with known payload length. Moreover, we have verified 
that the packet lengths are correctly added using the data from 
the active timeout test. We have discovered that the length of 
the single packet is always 14 bytes larger than expected. The 
Figure 3 shows a structure of a packet with Ethernet header. 
No VLAN tags have been used in our test, therefore the length 
of L2 header was exactly 14 bytes. Consequently, we conclude 
that the length of L2 header is incorrectly counted in the packet 
length field. This deficiency can be compensated for by simply 
subtracting packets ■ 14 bytes from the reported length at a 
collector. Flowever, it can easily lead to incompatibility with 
other tools and distorted measurement results. We have also 
confirmed that when L3 payload is shorter than 46 bytes, the 
padding is not included in the packet length, which is a correct 
behaviour. 
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Fig. 3. Ethernet header structure. 


Packet count is important as many detection methods use 
it to find patterns in a communication behaviour. The value of 
packet counters were checked using the same tests as for active 
timeout. We did not observe any irregularities and conclude, 
that this value is exported correctly using the NetFlow v5 
protocol. 

Other values are constant for each packet of the flow, 
therefore no aggregation is needed to report these values. 
We have checked all elements available in the NetFlow v5 
protocol on traffic generated during other tests. Since we 
did used the switch for Layer 2 switching only, we did not 
test correctness of autonomous system numbers and network 
prefixes. However, we found out that all other values are 
exported correctly. 


created correctly. IPv6 is supported only in NetFlow v9 
protocol, which is not implemented in Open vSwitch, and 
IPFIX protocol, which is implemented very poorly. However, 
IPv6 flows are at least exported by the IPFIX protocol, even 
when their quality is insufficient for most purposes. 

D. Packet Fragmentation 

Handling packet fragmentation in flow monitoring process 
is not a straightforward task. The problem is that flows 
are usually created from Layer 3 and Layer 4 information. 
However, only the first fragment carries Layer 4 information, 
therefore two different flow records are usually created for 
fragmented packets. The first flow contains only first segment 
of each fragmented packet and carries information about Layer 
4. The second flow contains only Layer 3 information and is 
created from the rest of the fragments. When multiple different 
connections between two devices use fragmented packets, a 
single flow record containing all subsequent packet fragments 
from each connection is created, since there is no Layer 4 
information to distinguish the flow records. The situation for 
single connection is depicted in Figure 4. 
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Fig. 4. Flows created from fragmented packets. 


We have tested flow monitoring on fragmented IPv4 pack- 
ets. Since the switch must correctly decide where to send 
packets even when they are fragmented, we thought it possible 
that fragmented packet will be exporter correctly as one flow. 
We tested the fragmentation using ping utility. Setting required 
payload to 9000 bytes caused the packet to be fragmented. 
Destination port is used to describe type of service in ICMP 
traffic in NetFlow v5, therefore we were able to observe 
different behaviour of the fragmented traffic. We found that 
the Open vSwitch does not combine fragmented packets to 
single flow and behaves exactly as shown in Figure 4. 


C. Supported Protocols 

The Layer 2 to Layer 4 protocols supported by Open 
vSwitch should be also supported by its flow monitoring 
process. We expect that the use of tunneling protocols, such 
as GRE and VXLAN, is transparent to the flow monitoring. 
However, further tests are required to verify this assumption. 
We tested flow export for following common Layer 3 and 
Layer 4 protocols: IPv4, IPv6, TCP, UDP, and ICMP. Each 
test consisted simply of sending a packet for each combination 
of these protocols. The NetFlow v5 export does not support 
IPv6 protocol and no flow records were exported for IPv6 
traffic. Other protocols are supported and flow records were 


IV. Conclusions 

We have evaluated the implementation of flow measurement 
of the Open vSwitch. We proposed and performed several test 
that cover the most important features of the flow monitoring 
process. Flow records were exported using both NetFlow v5 
and IPFIX protocols. The collected data was compared to pro- 
tocol specification and measurement artifacts were identified. 

The most surprising finding is that the implementation 
of IPFIX protocol has severe deficiencies that impede its 
deployment. The timestamps in flow records as well as packet 
counter reported nonsensical values. Therefore, we were not 
even able to perform all of the tests for the IPFIX protocol. 










TABLE II 

Open vSwitch network flow export support. 

/ - CORRECT. X - INCORRECT. N/A - NOT SUPPORTED. 



NetFlow v5 

IPFIX 

Flow expiration 

Inactive timeout 

N/A 

N/A 

Active timeout 

/ 

X 

RST/FIN TCP flags 

/ 

- 


Value Validation 


TCP Flags 

/ 

- 

Byte count 

X 

- 

Packet count 

/ 

X 

Basic Flow Keys 

/ 

- 

Flow duration 

X 

X 


Our evaluation of NetFlow v5 export showed that most of 
the values are exported correctly and as expected. However, 
number of bytes in packets include the length if Layer 2, 
although it should include only the length of Layer 3. More- 
over, the flow start timestamps of flow records expired due to 
active timeout are not zeroed. Therefore, flow record longer 
than active timeout can be observed. Moreover, most flow 
processing tools are not ready to handle the timestamps in this 
fashion and will report erroneous values for derived statistics, 
such as number of packets per second. Since NetFlow v5 is 
not able to export IPv6 protocol, its utility is limited in modern 
networks. Table IV shows overview of tested properties and 
results of the tests. 

The Open vSwitch is popular and widely used open source 
SDN switch. Our results show that its flow monitoring 
functions are poorly implemented and should receive more 
attention in the future. We believe that the IPFIX protocol 
should be implemented properly, since it allows to monitor 
IPv6 protocol and has many other features that are not present 
in the NetFlow v5 protocol. 
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